In the context of computer software, an application program, sometimes referred to as an "application," is a complete, self-contained computer program that performs one or more specific functions directly for a user. Application programs are sometimes integrated to create a "vertical application." Vertical applications are created when it is useful or convenient to have two or more application programs integrated together. The application programs in a vertical application are referred to as "sub-applications."
For example, a database application, a spreadsheet application and a word processing application may be integrated to create a vertical application. Then, database data can be retrieved by the database sub-application and passed directly to the spreadsheet sub-application for processing. The spreadsheet sub-application can then pass the spreadsheet data to the word processing sub-application to be used in a document. The spreadsheet data can also be sent by the spreadsheet sub-application back to the database sub-application so that the database can be updated.
Vertical applications are also created for specific situations, such as particular industries or particular customers. For example, a vertical application may include generic database, spreadsheet and word processing sub-applications and a custom financial sub-application developed for a particular industry.
One of the most difficult aspects of creating a vertical application is providing a way for sub-applications to communicate with each other. Sub-applications must communicate with each other when processing performed by one sub-application affects processing performed by another sub-application. In the previous example, output data generated by the spreadsheet sub-application is used as input data by the database sub-application.
One approach for providing communication between sub-applications is to implement a messaging scheme that allows sub-applications to exchange data using messages. A message is a body of data that is formatted according to a particular format. Each sub-application generates messages according to a particular format and then transmits the message to the other sub-applications.
When all of the sub-applications in a vertical application are developed by a single source, a single messaging scheme can be implemented across all of the sub-applications so that each sub-application is aware of all the other sub-applications and knows how to communicate with them. However, when the sub-applications are not all developed by a single source, some sub-applications may not be able to communicate with other sub-applications using messages because they do not support the same messaging scheme. Another problem is that some sub-applications are not necessarily designed to communicate with other sub-applications at all. Sub-applications that are not designed to communicate with other applications through messages are not "message aware".
One approach for providing communication between sub-applications that do not all support compatible communication formats, or that are not all message aware, is to update the source code of the sub-applications to implement a single message scheme in all of the sub-applications. With a single messaging scheme, each sub-application knows which other sub-applications it has to communicate with and how to communicate with those other sub-applications. However, in many instances, the source code of one or more sub-applications cannot be accessed or changed, making this approach unavailable. Even if the required source code can be accessed and changed, doing so can be impractical because changing the source code can require a large amount of resources and time. In addition, the invasive nature of this approach can adversely affect the reliability of those sub-applications.
Another approach for providing communication between sub-applications that do not all support compatible communication formats or that are not all "message aware" involves the use of adapters. An adapter is essentially a translator that translates data in one format to produce data in another format. The data before and after the translation contains the same information. However, the format of the data is changed. For example, an adapter may translate a message in format A to produce a message in format B.
When used in a vertical application, an adapter is "attached" to a sub-application to enable that sub-application to send messages to a target sub-application in the message format supported by the target sub-application without making significant changes to the sub-applications. An adapter may be integrated into its corresponding sub-application or may be more loosely associated with its corresponding sub-application. When the sub-application transmits or "publishes" a message to a target sub-application, the adapter ensures that the published message is in the format expected by the target sub-application so that the target sub-application will be able to successfully decipher the message. When the sub-application receives or "subscribes" to a message from the target sub-application, an adapter ensures that the received message is in the format expected by the sub-application so that the sub-application will be able to successfully decipher the message.
For example, consider FIG. 1, which illustrates a vertical application 100 that includes four sub-applications identified as SUB-APP1, SUB-APP2, SUB-APP3 and SUB-APP4. Sub-application SUB-APP1 supports messages that are in format 1. This means that sub-application SUB-APP1 transmits messages in format 1 and can successfully decipher messages received in format 1. Sub-application SUB-APP2 supports messages that are in format 2. Thus, sub-applications SUB-APP1 and SUB-APP2 cannot successfully communicate with each other directly because they support incompatible message formats.
According to the adapter approach, an adapter A1 is attached to sub-application SUB-APP1 and translates messages transmitted by sub-application SUB-APP1 in format 1 to produce messages in format 2. When a message is sent by sub-application SUB-APP1 to sub-application SUB-APP2, in format 1, the message is translated by adapter A1 to produce a message in format 2 that is sent to sub-application SUB-APP2. Thus, adapter A1 allows sub-operation SUB-APP1 to send messages to sub-application SUB-APP2 that can be successfully deciphered by sub-application SUB-APP2.
To allow sub-application SUB-APP2 to send messages to sub-application SUB-APP1 that sub-application SUB-APP1 can understand, an adapter A2 is attached to sub-application SUB-APP2 which translates messages transmitted by sub-application SUB-APP2 in format 2 to produce messages in format 1. When a message is sent by sub-application SUB-APP2 to sub-application SUB-APP1 in format 1, the message is translated by adapter A2 to produce a message in format 1 which is then sent to sub-application SUB-APP1. Thus, adapters A1 and A2 allow sub-applications SUB-APP1 and SUB-APP2 to successfully communicate with each other even though they support different message formats.
Sub-application SUB-APP1 also needs to communicate with sub-application SUB-APP3. However, sub-application SUB-APP3 only supports messages in format 3. To allow sub-application SUB-APP1 to send messages to sub-application SUB-APP3 that sub-application SUB-APP3 can understand, an adapter A3 is attached to sub-application SUB-APP1 which translates messages in format 1 to produce messages in format 3. When a message is sent by sub-application SUB-APP1 to sub-application SUB-APP3 in format 1, the message is translated by adapter A3 to produce a message in format 3 which is then sent to sub-application SUB-APP3. An adapter A4 is attached to sub-application SUB-APP3 which translates messages in format 3 to produce messages in format 1. When a message is sent by sub-application SUB-APP3 to sub-application SUB-APP1 in format 3, the message is translated by adapter A4 to produce a message in format 1 which is then sent to sub-application SUB-APP1. Thus, adapters A3 and A4 allow sub-applications SUB-APP1 and SUB-APP3 to communicate with each other even though they support different message formats.
Although adapters allow sub-applications that support different message formats to successfully communicate with each other, using adapters can have some drawbacks, particularly when the number of sub-applications in a vertical application is large. Adapters behave like direct connections between sub-applications since a sub-application must know the identity of the sub-application to which it is sending and receiving messages so that the correct adapter can be used. In order for two sub-applications to exchange messages using adapters, two different adapters are required, one on each sub-application. For three sub-applications, six adapters are required. For four sub-applications, as illustrated in FIG. 1, twelve adapters are required. Consequently, the number of required adapters grows exponentially with the number of sub-applications, making the adapter approach non-scalable.
Besides the large number of adapters that are required for some vertical applications, maintaining the adapters can require significant resources. If a message format supported by a sub-application is changed, all of the adapters for sub-applications that support the changed message format must be changed. In addition, adapters attached to other sub-applications used to communicate with the sub-applications that support the changed message format must be updated. For example, in FIG. 1, if the message format for sub-application SUB-APP1 is updated, then adapters A1, A3 and A5 that are attached to sub-application SUB-APP1 must be updated so that messages in format 1 can be properly translated into messages in formats 2, 3 and 4, respectively. In addition, adapters A2, A4 and A6 must be updated so that messages in message formats 2, 3 and 4 can be properly translated into messages in format 1. Thus, even a small change to only a single message format can require changes to a large number of adapters.
In addition, if a new sub-application is added to the vertical application that supports another message format, then an entire new set of adapters must be created for the new sub-application to enable the new sub-application to communicate with other sub-applications. New adapters must also be added to each sub-application that the new sub-application is to communicate with. Thus, changes to existing message formats, or adding a new sub-application that supports a different message format can require a large amount of resources and time to maintain existing adapters and create new adapters. This makes the adapter approach undesirable, particularly for vertical applications that have a large number of sub-applications.
Based on the need to provide communication between sub-applications in vertical applications and the limitations in the prior approaches, an approach for providing communication between sub-applications that avoids the use of adapters that translate between a message format supported by one sub-application and a message format supported by another sub-application as previously described is highly desirable.